home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 1719 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.5 KB  |  66 lines
  1. Newsgroups: comp.lang.c
  2. Path: in1.uu.net!tellab5!news
  3. From: Joe Toth <toth@tellabs.com>
  4. Subject: alarm()/setitimer() signals cause terminal 'bell/flash' (Was - Re: (no subject))
  5. X-Nntp-Posting-Host: sunh25
  6. Content-Type: text/plain; charset=us-ascii
  7. Message-ID: <1996Jan16.140026.15483@tellab5.tellabs.com>
  8. Sender: news@tellab5.tellabs.com (News)
  9. Content-Transfer-Encoding: 7bit
  10. Organization: Tellabs Operations, Inc.
  11. References: <1996Jan15.174105.22784@tellab5.tellabs.com> <4dek8i$qjf@chianina.au.wang.com>
  12. Mime-Version: 1.0
  13. Date: Tue, 16 Jan 1996 14:00:26 GMT
  14. X-Mailer: Mozilla 1.1 (X11; U; SunOS 4.1.3 sun4c)
  15. X-Url: news:4dek8i$qjf@chianina.au.wang.com
  16.  
  17. Jeremy Lee <jeremy_lee@ccmail.au.wang.com> wrote:
  18. >Joe Toth <toth@tellabs.com> wrote:
  19. >[...]
  20. >>The Scenario;
  21. >[...]
  22. >>  I perform my functions and set
  23. >>  the signals to allow for a proper return to the code when the interrupt
  24. >>  occurred.  For some reason, the 'bell' character is output to the terminal
  25. >>  which causes the audio/screen flash on the monitor.  The standard code
  26. >>  is executing in a system call (read) when the SIGALRM is generated.
  27. >[...]
  28. >
  29. >alarm() can't do that. read() can't do that. You MUST have something queued
  30. >in the output buffer that has not been flushed by any of the canonical
  31. >processing until the interrupt occurs. Try flushing the buffer ?TCIOFLUSH?
  32. >(termios.h) via an ioctl. While this might make the problem go away, it 
  33. >would be better to find out whats ready to print and where it came from.
  34.  
  35. I know that the alarm() and setitimer() do not do an alarm (bell)
  36. automatically (at least according to the man page).  And I know that
  37. read on its own is not doing the alarm.
  38.  
  39. I have verified that there is no output needing a flush, and the problem
  40. persists.
  41.  
  42. I have a feeling it is because the signal (SIGALRM) is occuring during
  43. the system call to read().  I tried changing the read to getchar(), and
  44. the same symptom exists.
  45.  
  46. I realize that the 'bell' is proobably system generated.
  47. I just want to get rid of it.
  48.  
  49. >-- 
  50. >----------------------------------------------------------------------
  51. >Jeremy Lee
  52. >Wang Australia
  53. >jeremy_lee@ccmail.au.wang.com
  54. >
  55.  
  56. -- 
  57.   _  _  ___  --------------------------+---------------------------------
  58.   | / _  |    Joseph G. Toth Jr.       | Tellabs Operations, Inc.  
  59. \_| \_/  |                             | toth@tellabs.com
  60.  
  61. > Every program has at least one bug and can be shortened by at least
  62. > one instruction -- from which, by induction, it is evident that every
  63. > program can be reduced to one instruction that does not work.
  64. >                       -- Ken Arnold
  65.  
  66.